News for hackers. Stuff that matters.

ushakov

Re:The VMs Powering Mobile Agents (Instinct, Claude Code) on Tuesday September 08, 2026 @10:13AM (#49610635)
my thoughts is that Firecracker might be not the best runtime for that, as it’s very minimal on devices it wants to support (famously no PCI out of the box)
Re:The VMs Powering Mobile Agents (Instinct, Claude Code) on Tuesday September 08, 2026 @10:07AM (#49610561)
Amp’s Orbs run on E2B.

E2B is fully open-source under Apache 2.0 and runs on GCP, AWS, Azure (preview) and locally on any Linux box that has /dev/kvm (Mac works via Colima, too).

source: https://github.com/e2b-dev/infra

Re:The VMs Powering Mobile Agents (Instinct, Claude Code) on Tuesday September 08, 2026 @06:29AM (#49608353)
hey, i work at E2B, happy to answer any questions!
Re:OpenAI: Migrating to HTTPX2 on Saturday August 29, 2026 @09:23AM (#49489712)
because pyqwest is what official connect Python library uses and we wanted to follow that
Re:OpenAI: Migrating to HTTPX2 on Friday August 28, 2026 @12:18PM (#49480733)
we have recently switched from httpx for the same reason but instead went with the Rust-based pyqwest (runs on Hyper) it has also a drop-in httpx-compatible transport so migration was easy and also it supports http2 trailers

https://pyqwest.dev

i’d say what AWS released looks closer to a bare compute primitive. E2B is up the stack and ships everything around VM like snapshots, networking, integrations.

also, there’s no lock-in, E2B is open-source and can be hosted on any cloud (AWS included).

plus supports bigger boxes, higher concurrency, longer timeouts (24hr).

disclaimer: i work at E2B

the code is not public, so we can't know. i think it's much more nuanced and certain users' comments might get a preferential treatment, based on factors other than the upvote count - which itself is hidden from us.
of course your comment attracts more upvotes - it's at the top.
i don't doubt this. i just find it questionable that one particular poster always gets in the spotlight when AI is the topic - while other conversations in my opinion offer more interesting angles.
i am curious, why are your comments always pinned to the top?
Re:AWS Adds support for nested virtualization on Friday February 13, 2026 @10:37AM (#47003898)
We are running Sandboxes for AI Agents using Firecracker microVMS @ E2B
$1.5M seed bets, maybe. not $60M though
Re:Matchlock: Linux-based sandboxing for AI agents on Sunday February 08, 2026 @08:29AM (#46934023)
just from looking at it

on Linux it runs Firecracker: https://github.com/jingkaihe/matchlock/blob/main/pkg/vm/linu...

on macOS uses the Apple's Virtualization.Framework Go wrapper: https://github.com/jingkaihe/matchlock/blob/main/pkg/vm/darw...

Re:Matchlock: Linux-based sandboxing for AI agents on Sunday February 08, 2026 @07:08AM (#46933574)
very cool, if you want cross-platform microvms, there's an interesting project called libkrun that powers projects like Podman and Colima.

here's a Go binding: https://github.com/mishushakov/libkrun-go

demo (on Mac): https://x.com/mishushakov/status/2020236380572643720

Re:Python interpreter written in Rust for use by AI on Friday February 06, 2026 @08:48PM (#46920508)
i think there’s a confusion around what use-case Monty is solving (i was confused as well). this seems to isolate in a scope of execution like function calls, not entire Python applications
Re:Python interpreter written in Rust for use by AI on Friday February 06, 2026 @08:46PM (#46920495)
we’re not disagreeing here - i meant for general use-case VMs are better, for some application-specific calls Monty this might suffice.

although you’d still need another boundary to run your app in to prevent breaking out to other tenants.

Re:Python interpreter written in Rust for use by AI on Friday February 06, 2026 @08:32PM (#46920399)
agree. you still need a secure boundary like VM to isolate the tenants in case the model breaks out of the sandbox.

everything that you don’t want your agent to access should live outside of the sandbox.

Re:Python interpreter written in Rust for use by AI on Friday February 06, 2026 @08:23PM (#46920355)
best answer is probably to have a layered approach - use this to limit what the generated code can do, wrap it in a secure VM to prevent leaking out to other tenants.
Re:Python interpreter written in Rust for use by AI on Friday February 06, 2026 @08:19PM (#46920338)
there’s no way around VMs for secure, untrusted workloads. everything else, like Monty has too many tradeoffs that makes it non-viable for any real workloads

disclaimer: i work at E2B, opinions my own

Re:Deno Sandbox on Tuesday February 03, 2026 @05:21PM (#46878179)
Factory, Nvidia, Perplexity and Manus are using E2B in production - we ran more than 200 million Sandboxes for our customers
Re:Sandboxing AI Agents in Linux on Tuesday February 03, 2026 @04:46PM (#46877774)
for personal use, many ways: Vargant, Docker Sandbox, NixOS VMs, Lima, OrbStack.

if you want multi-tenant: E2B (open-source, self-hosted)

Re:Deno Sandbox on Tuesday February 03, 2026 @04:30PM (#46877569)
we aren’t worried about that.

when we were starting out we figured there was no solution that would satisfy our requirements for running untrusted code. so we had to build our own.

the reason we open-sourced this is because we want everyone to be able to run our Sandboxes - in contrast to the majority of our competitors who’s goal is to lock you in to their offering.

with open-source you have the choice, and luckily Manus, Perplexity, Nvidia choose us for their workloads.

(opinions my own)

Re:Deno Sandbox on Tuesday February 03, 2026 @03:56PM (#46877182)
we offer secure cloud VMs that scale up to 100k concurrent instances or more.

the value we sell with our cloud is scale, while our Sandboxes are a commodity that we have proudly open-sourced

Older »