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.

Comments URL: https://news.ycombinator.com/item?id=49199885

Points: 3

# Comments: 0

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.

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

It makes Codeberg seem like an unserious project.

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.

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

You'd have to build more of that with libkrun

The core tech of both are great though.

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/)

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

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/

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

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

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

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

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

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.