Aether – Background agents that fix bugs in isolated VMs, opens PRs
Hey HN, I've been building Aether, a background agent that takes production errors from Sentry and attempts to turn them into verified pull requests. When a new error hits your Sentry project: 1. Sentry webhook fires with the stack trace, breadcrumbs, and context 2. Aether spins up an isolated Fly.io VM and clones the repo at the relevant commit 3. Agent analyzes the stack trace, reproduces the issue, proposes a fix 4. Starts the dev server, re-runs tests, and can verify the running app with Playwright (headless Chromium is pre-installed in every VM) 5. A review pass evaluates the diff…
What it does
In the maker’s words, at launch
Hey HN, I've been building Aether, a background agent that takes production errors from Sentry and attempts to turn them into verified pull requests. When a new error hits your Sentry project: 1. Sentry webhook fires with the stack trace, breadcrumbs, and context 2. Aether spins up an isolated Fly.io VM and clones the repo at the relevant commit 3. Agent analyzes the stack trace, reproduces the issue, proposes a fix 4. Starts the dev server, re-runs tests, and can verify the running app with Playwright (headless Chromium is pre-installed in every VM) 5. A review pass evaluates the diff before a PR is opened 6. Pushes to a feature branch and opens a GitHub PR, but only if verification succeeds 7. If CI fails, it retries once with the failure logs. If it fails again, the task is marked failed. No infinite loops. Why full VMs instead of worktrees? Each task runs in its own isolated machine with a real filesystem, real process model, real network stack. It can `npm install`, run a dev server on port 3000, and Playwright can hit `localhost:3000` because it's an actual environment, not a sandbox. Since each task is its own VM, preview URLs are exposed per task via a gateway proxy so you can inspect the running app while the agent works. VMs shut down shortly after the task completes. There's a simple multi-agent setup: a solver proposes the fix, a review agent evaluates the diff, and the fix has to survive re-execution in a clean isolated environment before a PR gets opened. Not claiming formal guarantees here, just requiring the fix to actually execute successfully in a reproducible environment before it touches your repo. Limitations: - Works best on well-tested codebases where "reproduce and verify" is meaningful - If reproduction isn't deterministic, results degrade - CI retry is capped at one automatic attempt - Code review is model-driven, not an architectural enforcement layer - BYOK only, you bring your own API key via OpenRouter. No markup on model costs but it's not super cheap to run - Sentry integration is built but waiting on approval from Sentry, coming soon - CLI is also coming soon Bug fixing is the main focus but it's built on top of a general-purpose background agents system that works today. The agent is still great at general coding tasks. You can give the agent tasks from a full web IDE with a code editor, terminal, file tree, and agent chat panel. CLI is coming soon too (`aether run "add auth to the API"`). Each task gets its own isolated VM with shareable preview URLs so you can hand someone a link to see exactly what the agent built. Similar to Cursor background agents but running in the cloud with full environment isolation instead of local worktrees. Stack: Go API (Chi), Fly.io VMs, React 19 + Vite frontend, Bun workspace service inside each VM, Supabase for auth/db/realtime, Playwright + Chromium preinstalled on each VM. Self-serve right now: GitHub OAuth, connect a repo, and go via the web IDE. Sentry and CLI coming soon. Would value feedback from engineers who deal with production debugging regularly, or frequently use background agents. Where would this break, and what would make you trust it? Landing page: https://www.runaether.dev Try it: https://app.runaether.dev
Does the same job
all alternatives →
- GYGive your coding agent production bug contextNov 2025 · sonarly.dev · ▲5
Hi all, I've been working on this devtool for 1 month now for myself at first and I'll be curious to see if it's something that could work for you as well. So basically, it detects bugs in your website in production from real user sessions, an llm clusters them by severity and it provides the complete context of the issue that you can copy-paste into your coding agent to fix it in one go. Why did I create it? I've been shipping fast with tools like Cursor and Claude Code. The problem? When bugs happen in production, these tools have zero context about what actually went wrong. Sentry is…
More ai this month
the category →
I trained a 125M-parameter transformer to autocomplete piano performances in real time (~108 notes/sec on an iPhone 15). The idea is basically GitHub Copilot or Tabnine, except instead of prompting it with code, you prompt it by playing a few notes on a MIDI piano. The model then continues what you played, entirely on-device. The app is free if anyone wants to try it. Happy to answer questions about the model, training, Core ML, or the many things that didn't work.
AI · 17d ago · simedw.com
Astute▲585Automate your B2B brand going viral, with new media creators
AI · 18d ago · company-app.joinastute.com
Hey HN, Henry from Cactus here! We previously released Cactus Needle, a 14MB agentic LLM for tool call, device use, and structured extraction for phones, wearables, smart homes, small robots and microcontrollers. We got really great feedback here, and have now incorporated the suggestions to release Needle 2. The whole model is a single 14MB binary that runs a full session in 28MB of RAM; 45m parameters at 2bit compression. Needle hits 500 tokens/sec decode speed on a Raspberry Pi 5, sits between 400-1,500 tokens/sec on VR devices like Meta Quest 3S and Apple Vision Pro, and ranges…
AI · 26d ago · cactuscompute.com
