dbmikus

My startup is open core: https://github.com/gofixpoint/amika

We run cloud sandboxes, and have some experimental local sandbox support that is fully OSS.

Main thing for amika.dev is you can control the sandboxes and agents interchangeabley by SSH, web, or API, and can expose the services the agent is working on over signed URLs

Entire sandbox config is a TOML file

We're going to improve the local OSS sandbox mode and add better network controls over the next couple weeks.

Ultimately, what we're building kind of like if Tailscale and Firecracker had a baby, with a messaging protocol for remote controlling any sandboxed agent

It's free to try out. Still a lot to build, so we really appreciate any and all feedback about what we should focus on

I'm working on https://www.amika.dev/, which lets you put sandboxed agents on cloud VMs and then message them over the internet.

It's for agent + human devboxes, for chatting with coding agents from the web, or automating them with an API. Thing like Claude Code web, but any agent and you directly control the VM, too.

We're working to make amika.dev work on any computer, homelab, or K8S cluster. For tech folks, I describe it kinda like if Tailscale and Firecracker had a baby.

time to bring back the dev email distribution list

Nope, but I thought about moving hosting (or to Forgejo) because of (a) GitHub's issues, and (b) I like the idea of using an OSS code forge

I suppose since Codeberg is a totally free non-profit for OSS projects, it makes it more reasonable for them to ban code for idealogical differences (as opposed to legal).

But if it were a paid service, this would not inspire confidence that it's a place to host my company's code.

Identity is more than a name. It is also proving that you own that identity (aka authentication)

But the identity part of git is not (unless you count pgp signing of each commit, which never took off at a large scale)

and the git tools don't automatically propagate repo changes by default across a network

Well, definitely makes me inclined to never use Codeberg for source hosting if they can just get together and decide to ban an entire category of source repo.

It makes Codeberg seem like an unserious project.

Really freaky seeing how many of these are bedrooms.

Is the talk going to be shared online anywhere? Would be interested in checking it out later!

exe.dev is great, but the VMs are not really "apps". They are durable computers / VMs.

An example of a "sandboxed agent app", would be: give the app all your past emails. An agent scans them and finds sales emails you need to follow up on. It shows you the suggested follow ups in a UI, and you approve/reject them. Then, it mass sends the approved emails and emits an update to your CRM with the changes.

The sandbox is deleted when the app runs. It's ephemeral for the lifecycle of the app. And you can re-run the same app repeatedly with new inputs, but it gets the same clean starting slate.

Def!

My personal belief is that the future of an "app" is a combo:

    1. micro VM
    2. agent on the VM
    3. software bundled into the VM

So, it should be stupid simple to run these local sandboxed apps/agents. Right now, not too hard for technical users (esp. with things like https://smolmachines.com/ and https://microsandbox.dev/), but not as easy as clicking an app icon or typing `/path/to/binary` in the CLI

Firecracker has more tooling for the orchestration layer that manages many sandboxes at once. Stuff like K8S integration, an external REST API control plane, more first-class support for snapshotting, etc.

You'd have to build more of that with libkrun

The core tech of both are great though.

Why do you want to self-host vs. using one of the many providers out there?

Daytona, E2B, OpenComputer, Freestyle, Blaxel, Vercel, Modal, Cloudflare, Tensorlake, Superserve, etc. etc.

Some of them work by pre-purchasing credits, so you can control the blast radius of spend.

Also, if you want a more embedded sandbox runtime as a library instead of a daemon + REST API, you can check out libkrun (and friendly layers on top of it like https://microsandbox.dev/ and https://smolmachines.com/)

There are sooooo many sandbox providers out there.

They do spike on different features like:

    - snapshotting and forking
    - good SSH and VPN access for end-users
    - agent-friendly features, like obscuring secrets at network layer

Then there's also the option to use libkrun to run local sandboxes on your own computer. That doesn't scratch the itch for hosted services, but works if your goal is to run agents inside isolated environments for your own work.

I've been working on some open-core stuff[1] to coordinate sandboxes, and we're making changes to have a library that lets people coordinate any number of remote or local sandboxes using any provider, kinda like how the Docker CLI works for managing containers, git repos, and coding agents. Flue[2] is another player in this space, and is more of a pure framework, while we're building it as an interactive product for using sandboxed agents and workflows.

[1] https://github.com/gofixpoint/amika/blob/main/ROADMAP.md

[2]: https://flueframework.com/

Yes, running locally certainly helps if you want your sandboxed AI to be able to use the internet without getting blackholed by Cloudflare

Yeah, Docker Sandbox is in the right direction. But there's a lot of parts that are still not ironed out yet.

How do you package a Docker Sandbox up into an app that can expose UI widgets, with an agent hiding behind them? What widgets is the agent allowed to modify? How do you run a workflow like "give agent all these files, modify the files, and do changeset management on the modifications?"

I'm not 100% sure which part of these will be baked into the application standard format, and which are orthogonal. But current way of packaging up and running these agents doesn't feel right.

I think about this a lot because my startup is building cloud VMs for agents to do code-gen and auto-validate changes, so we have a workflow like:

    1. git repo, skills, CLI tools, biz context goes in
    2. agent iterates against running dev environment
    3. changes go out into git PRs and CI

I think this type of app/agent workflow will expand outside coding use-cases.

Understand that it is annoying to spin up a heavyweight VM whenever running Claude Desktop, but I actually think per-app + agent virtualization is the future. Next version of an app is:

    1. micro VM
    2. agent on the VM
    3. software bundled into the VM

Then the agent is totally sandboxed at the hardware virtualization level. It can use the software tools on the VM or write its own. VM can control which software is "frozen" and which is open to agent modification. And VM can also control which services are exposed outside the VM through sockets, HTTP server, X window system, whatever

It's self-modifying apps that are sealed off from touching parts of the computer they shouldn't.

Claude Code's dynamic workflows are AI-generated JavaScript, so unlike `/goal` they can in theory import libraries and perform I/O (not sure that they can currently).

On checkpointing: I explained myself poorly. You're right that using higher level workflows doesn't turn off checkpointing. One can simply make harnesses non-interactive, but that can make models lose coherence over long tasks (because they can't ask for feedback). A higher level coordinator (/goal, CC dynamic workflows) is designed to provide this feedback without human intervention.

On price: older models keep getting cheaper, and most tasks don't need frontier capability. (I'm ignoring the part about subscription subsidies right now, and just talking about API price for tokens)

On my startup Amika: we run programmable cloud computers for agents, plus the workflow systems to guide them. We let people run any agent (Codex, Claude, etc.), prompt it from anywhere (Slack, web, CLI + SSH, API). It's like devboxes for humans + agents, with guardrails[1] to deterministically ensure things about the changes coding agents make (ie don't let agent modify module boundaries, require every DB query carry a multi-tenant org ID filter).

Maybe our website is bad at explaining it, in which case I appreciate any feedback!

[1]: https://docs.amika.dev/guides/code-annotations

To stop agents from pausing for checkpointing, you can have a deterministic outer loop that re-runs until a stop condition is met.

I think teams need to be able to write nested workflows that transition between code-led and agent-led, with either supporting human-in-the-loop checkpoints.

Been iterating on what this should look like at our startup (https://www.amika.dev/). Model labs are also improving capabilities here, such as Codex's `/goal` and Claude Code's dynamic workflows[1]

The points about API usage cost still stand, but model intelligence is getting cheaper every month! No need to use the frontier model for every part of the work.

[1]: https://code.claude.com/docs/en/workflows

I think with a proper managed agents platform, the user should have total control over the VM, the software on it, which model to use, and which agent harness to use. Then you can just override the system prompt and you don't need to follow Anthropic's rules!

Maybe Anthropic will give more control over configuring the Claude harness and VM, but they definitely won't let you swap out to other models and harnesses.

We've been building open core infra (https://github.com/gofixpoint/amika) for running any agent on any type of VM or sandbox, with the main use case for safely automating internal code-gen, but technically could repurpose our stack for anything.

There should be a model agnostic platform for running these types of agentic apps.

A couple other major open source harnesses:

- https://github.com/badlogic/pi-mono/ - https://github.com/anomalyco/opencode

Spaces help me visually organize related apps. I have all my chat apps in one, all my dev stuff in another.

I used to run Linux with i3 tiling window manager, but switched to Mac because the battery is so much better. Although the new Framework laptop looks like it has pretty great battery life.

I really like exe.dev's pricing model where I pay a fixed monthly fee for compute and then can split it up into as many VMs as I want. I use exe.dev to run little vibe-coded apps and it's nice to just leave them running without a spend meter ticking up.

We're thinking about switching to this pricing model for our own startup[1] (we run sandboxed coding agents for dev teams). We run on Daytona right now for sandboxes. Sometimes I spin up a sandboxed agent to make changes to an app, and then I leave it running so my teammate can poke around and test the running app in the VM, but each second it's running we (and our users) incur costs.

We can either build a bunch of complicated tech to hibernate running sandboxes (there's a lot of tricky edge cases for detecting when a sandbox is active vs. should be hibernated) or we can just provision fixed blocks of compute. I think I prefer the latter.

[1] https://github.com/gofixpoint/amika

Like the detailed setup instructions in the readme!

Also agree that teams should invest in their own harness (or maybe pedantically, build a system on top of harness likes Claude Code, Codex, Pi, or OpenCode)

Yes, I hate how slow it is to swipe between desktop workspaces, for example.

Curious if Andon has gone one level higher and has the AI decide what next real-world experiment it should do.

If you don't get it working with Claude Code Routines, would love to connect and see if we can help! We're building an open core product that can spin up sandboxed coding and control them from Slack (and also web UI, TUI, and HTTP APIs + CLIs)

We work with any coding model / harness.

website: https://www.amika.dev/

OSS repo: https://github.com/gofixpoint/amika

And my email is dylan@amika.dev (I'm one of the founders)

We might be building something up your alley! I wanted an OSS platform that let me run any coding agent (or multiple agents) in a sandbox and control it either programmatically or via GUI / TUI.

Website is https://amika.dev

And part of our code is OSS (https://github.com/gofixpoint/amika) but we're working on open sourcing more of it: https://docs.google.com/document/d/1vevSJsSCWT_reuD7JwAuGCX5...

We've been signing up private beta users, and also looking for feedback on the OSS plans.

necro-posting here, but that's kinda what we're working on! We're focused on creating cloud workspaces for sandboxed coding agents and it's built to support any agent harness. https://www.amika.dev/

Under the hood, we're open sourcing a lot of the parts for provisioning these agents, their VMs/sandboxes, and managing agent messaging + sessions. Put our open source plans here: https://docs.google.com/document/d/1vevSJsSCWT_reuD7JwAuGCX5...

I'm a cofounder of Amika (https://www.amika.dev/) (OSS repo: https://github.com/gofixpoint/amika).

We let users spin up sandboxed coding agents in the cloud, and control them interactively or programmatically. Each sandbox comes loaded with your git repos, your pick of coding agents, agent skills, MCP servers, and CLI tools, plus a live preview environment so you and the AI can see changes in real time.

I like running `claude --dangerously-skip-permissions` in Amika because worst case, I just delete the sandbox. You can also spin them up via API/CLI to do things like catch Sentry issues and auto-fix them in the background.

Little demo: https://youtu.be/OZzdBNBXxSU?si=4BwPQmFNq94-5T6H

We're excited about "software factories": using code-gen automations to produce more of your code. We still review everything that lands, but the process of producing those changes is getting more hands-off.