Here's a demo: https://www.youtube.com/watch?v=ttMl96l9xPA.
Our biggest pain point with hosting agents was that you'd need to stitch together multiple pieces: packaging your agent, running it in a sandbox, streaming messages back to users, persisting state across turns, and managing getting files to and from the agent workspace.
We wanted something like Cog from Replicate, but for agents: a simple way to package agent code from a repo and serve it behind a clean API/SDK. We wanted to provide a protocol to communicate with your agent, but not constraint the agent logic or harness itself.
On Terminal Use, you package your agent from a repo with a config.yaml and Dockerfile, then deploy it with our CLI. You define the logic of three endpoints (on_create, on_event, and on_cancel) which track the lifecycle of a task (conversation). The config.yaml contains details about resources, build context, etc.
Out of the box, we support Claude Agent SDK and Codex SDK agents. By support, we mean that we have an adapter that converts from the SDK message types to ours. If you'd like to use your own custom harness, you can convert and send messages with our types (Vercel AI SDK v6 compatible). For the frontend, we have a Vercel AI SDK provider that lets you use your agent with Vercel's AI SDK, and have a messages module so that you don't have to manage streaming and persistence yourself.
The part we think is most different is storage.
We treat filesystems as first-class primitives, separate from the lifecycle of a task. That means you can persist a workspace across turns, share it between different agents, or upload / download files independent of the sandbox being active. Further, our filesystem SDK provides presigned urls which makes it easy for your users to directly upload and download files which means that you don't need to proxy file transfer through your backend.
Since your agent logic and filesystem storage are decoupled, this makes it easy to iterate on your agents without worrying about the files in the sandbox: if you ship a bug, you can deploy and auto-migrate all your tasks to the new deployment. If you make a breaking change, you can specify that existing tasks stay on the existing version, and only new tasks use the new version.
We're also adding support for multi-filesystem mounts with configurable mount paths and read/write modes, so storage stays durable and reusable while mount layout stays task-specific.
On the deployment side, we've been influenced by modern developer platforms: simple CLI deployments, preview/production environments, git-based environment targeting, logs, and rollback. All the configuration you need to build, deploy & manage resources for your agent is stored in the config.yaml file which makes it easy to build & deploy your agent in CI/CD pipelines.
Finally, we've explicitly designed our platform for your CLI coding agents to help you build, test, & iterate with your agents. With our CLI, your coding agents can send messages to your deployed agents, and download filesystem contents to help you understand your agent's output. A common way we test our agents is that we make markdown files with user scenarios we'd like to test, and then ask Claude Code to impersonate our users and chat with our deployed agent.
What we do not have yet: full parity with general-purpose sandbox providers. For example, preview URLs and lower-level sandbox.exec(...) style APIs are still on the roadmap.
We're excited to hear any thoughts, insights, questions, and concerns in the comments below!
I suspect it works as follows: when a task starts, filesystem contents sync down from S3/R2/GCS to a local directory, which gets bind-mounted into the container. The agent reads and writes normally - no FUSE, no network round-trips per file op. On task completion or explicit sync, changes flush back to object storage. The presigned URL support for upload/download is the giveaway that object storage is the source of truth.
This makes way more sense than FUSE for agent workloads. Agents do thousands of small reads (find, grep, git status) that would each be a network call with FUSE. With copy-on-mount it's all local disk speed after initial sync.
Cross-task sharing falls out naturally - two tasks mounting the same filesystem ID just means two containers syncing from the same S3 prefix. Probably last-write-wins rather than distributed locking, which is fine since agents rarely have concurrent writes to the same file.
* https://fly.io/blog/design-and-implementation/ * https://juicefs.com
One area I'd love to understand better: inter-agent communication and auditability. When multiple agents share the same filesystem (e.g., a coordinator agent and several sub-agents), how is message passing or state handoff handled? Is it purely file-based (agents read/write to agreed-upon paths), or is there a more structured IPC mechanism?
More importantly, from an audit perspective: is there a way to replay or inspect the full sequence of reads/writes and agent messages across a multi-agent task? For production use cases (document processing, internal tooling), being able to trace why an agent made a decision — and which files it read at that moment — feels like a hard requirement. Curious whether this is on the roadmap or expected to be handled at the application layer.
We're experimenting with multi-agent systems to figure out what the right API would be for agent to agent communication. We've found Claude Code's Team feature is a good starting point for the abstraction, but we think there's better abstractions and are creating the primitives to allow people do create custom definitions to explore.
Re: audit perspective. We have something we've been working on that we're excited to share soon which I think you'll like:)
The English that English speakers post on Hacker News is often grammatically incorrect, clumsy, misspelled, and that's okay, good, even. We want to hear from you!
(My preference is for translators to include both the original Chinese words, and the English translation because it means your fellow Chinese speakers get to read your exact words, but of course that is personal preference :)).
I have been building an OSS self-hostable agent infra suite at https://ash-cloud.ai
Happy to trade notes sometime!
1) Can I use this with my ChatGPT pro or Claude max subscription? 2)
Yes, you can use your own subscriptions as long as you follow their guidelines
(Disclaimer, I'm the CEO of Dagger)
I founded Docker, and lack of proper nesting support was always a pet pieve of mine. I couldn't fix it in Docker, so I fixed it in Dagger instead :)
When I read this, I think of Fly.io's sprites.dev. Is that reasonable, or do you consider this product to be in a different space? If the latter, can you ELI5?
One question: for the "existing tasks stay on old version" case, do you support any kind of manual migration trigger? E.g. if I fix a genuine bug in how I'm parsing a document, I might want to re-run the agent on specific old workspaces with the new version, rather than waiting for users to start new tasks.
> for the "existing tasks stay on old version" case, do you support any kind of manual migration trigger
Yes, we support manually migrating tasks using "tu tasks migrate".
> if I fix a genuine bug in how I'm parsing a document, I might want to re-run the agent on specific old workspaces with the new version, rather than waiting for users to start new tasks
In this case the better pattern is to create new tasks against those old workspaces on the fixed version. You could do this on behalf of your users.
Your two-step deployment (config.yaml + Dockerfile) with separate storage looks like it solves the iteration speed problem well. One thing I've found critical in practice: for agents that touch real infrastructure, you need explicit confirmation gates on destructive operations. Does Terminal Use have any built-in patterns for that, or is it left to the agent implementation?
I started by managing the claude agent sdk myself in a daytona container, and it was a lot more challenging than I thought. The agent kept crashing in streaming mode and there was no thread crash, so it was hard to debug, esp in a cloud container like Daytona. I also realized that I needed to implement my own session management system + my own database if I wanna save the chat and on top of that streaming so the messages come out in real time. AND I need to manage my own container janitor/heart beat system so that un-used containers don't just sit there, but I also don't want them to go cold immediately after each message since cold start takes a bit.. They all seem simple but at each step there are some edge cases. I ended up vibe coding most all of that, but it was just quite fragile. For those who hasn't tried the agent sdks, it feels like it's clearly designed to be ran on a client computers with permanent storage + lots of ram than microVMs. Which was not what I expected.
After that, I tried to find some managed option. Starting with blackbox ai because I saw a vercel tweet about them, and for some reason I just couldn't get their agent API stuff to work AT ALL?... I'm curious as to if it's actually working for anyone. Then I tried sandbox dev, which doesn't store container/sessions/storage stuff out of the box for you, so it wasn't much better than doing the daytona container myself. And then I tried terminaluse, and it worked better than I expected given all of the other stuff that I tried.
So at the end of the day, it's kind of like a managed cloud services that does agent chat history, session recovery, streaming + a CLI that makes it easy for my own codex to debug/deploy + file system sync. From what I can tell, there isn't anyone else that can do all that and I'm pretty pleased with using them.
I know OSS business models are rough, but someone is going to solve this in open source and I think that is what will achieve traction.
1. we're not NFS, we wrote our own protocol to get much better performance
2. we're planning on coming out with native branching this month, which should make these kinds of workloads much easier to build!
We're currently rolling our own but we've been meaning to experiment with other tools.
For example we make it easy to have automatic deployments from your github ci (using our cli), and you can monitor and manage all your deployments in our platform, along with logs, conversation transcripts etc.
I'd think of us more of the deployment, monitoring and storage layer rather than just the compute runtime.
eg. I already run Kubernetes
Agents run on infra, they have network connectivity, they have ACLs and permissions that let them read+write+execute on resources, they can interact with other agents.
To manage them from both an infra and security perspective, we can use the existing underlying primitives, but it's also useful to build abstractions around them for management, kind of like how microservices encapsulate compute+storage+network together.
I think of agents as basically microservices that can act in non-deterministic ways, and the potential "blast radius" of their actions is very wide. So you need to be able to map what an agent can do, and it's much easier to do that if there are abstractions or automatic groupings instead of doing this all ourselves.
The monitoring problem alone is closer to fraud detection than traditional APM. You're not looking for "is this thing up," you're looking for "is this thing subtly wrong in a way that compounds over the next 10 steps."
tl;dr, I don't think the shovel analogy holds up for most of the Ai submissions and products we see here.
If you repurpose k8s with ephemeral volumes or emptyDir, a sidecar, you'll likely get predictable ops and avoid vendor lock-in. Expect more operator work, fragile debugging across PVCs and sidecars, and the need to invest in local emulation or a Firecracker or gVisor sandbox if you want anything like laptop parity.
The hype is so large with the CLI coding tools I got FOMO, but as you were saying in that thread, I see no tangible improvement to the value I get out of AI coding tools by using the CLI alone. I use the CLI in VS Code, and I use the chat panel, and the only thing that seems to actually make a difference is the "context engineering" stuff of custom instructions, agent skills, prompt files, hooks, custom agents, all that stuff, which works no matter which interface you use to kick off your AI coding instructions.
Would be curious to hear your thoughts on the topic all these months later.
The reasons are (1) it's faster to do admin work like naming or deleting old sessions (2) I have not gotten the remote setup to work yet (haven't tried) but I do want to use it somewhere
But yeah, it's gotten worse, the latest I recall is a new diff viewer for AI in the terminal (I already have git and lazygit)
One thing I took from ATProto is a strong belief that user agency and choice are the penultimate design criteria. To those ends, I think that any agentic tooling needs to support the majority of users' choice about how to interact with it (SDK, API, CLI, TUI, IDE, and Web). My custom agent is headed that way anyhow, because there are times where I do want to reach for one of them, and it's easier to make it so with agents working on their own codebase (minus vscode because the testing/feedback I haven't figured out yet)
K8s is great at keeping things alive. It's not built to reason about whether the thing that's alive is actually working correctly. Agent infra needs to handle rollback at the logic level, not just the container level.
We're thinking a lot about how we could provide a "Convex" like experience where we guide your coding agents to set up your agents in a way that maximizes the ability to rollback. For example, instead of continuously taking action, it's better that agents gather all required context, do the work needed to make a decision (research, synthesize, etc.), and then only take action in the real world at the end. If an agent did bad work, then this makes it easy to rollback to the point where the agent gathered all the context, correct it's instructions, and try again
One thing we've run into: the filesystem abstraction works well for code artifacts, but when agents interact with external services (APIs, databases), you need a separate "action journal" that logs intended mutations before executing them. This gives you rollback even for side effects that aren't file-based.
The harder unsolved problem is multi-agent state coordination. When Agent A writes to a shared workspace and Agent B reads it, the filesystem gives you structural persistence but not semantic ordering. Have you thought about adding lightweight event ordering (like a simple monotonic sequence) to the filesystem layer? Without it, agents can read stale state even when files are fresh.
Congrats on the launch — the decoupled storage model is the right primitive.
> Our biggest pain point with hosting agents was that you'd need to stitch together multiple pieces: packaging your agent, running it in a sandbox, streaming messages back to users, persisting state across turns, and managing getting files to and from the agent workspace.
The k8s ecosystem already handles most this and your agent framework the agent specifics. What you are talking about is valid, though a different axis imo. Quality and guardrails are important, but not discussed by OP.
I think Kata containers with Kubernetes is an even better sandboxing option for these agents to run remotely.
Shameless plugin here but we at Adaptive [1] do something similar.
[1] https://adaptive.live
The permissions issues you mention are handled by SA/WIF and the ADK framework.
Same question to OP, why do you think I need a special tool for this?
We don't need to rebuild everything just for agents, except that people think they can make money by doing so. YC has disappointed me of late with the lack of diversity in their companies. I suspect the change in leadership is central to this.
With regards to permissions, mileage varies based on SDK. Some have very granular hooks and permission protocols (Claude Agent SDK stands out in particular) while for others, you need a layer above it since it doesn't come out of the box.
There are companies that solve the pain of authn/z for agents and we've been playing with them to see how we could complement them. In general, we do think it's valuable to be provide this at the infra level as well rather than just the application level since the infra layer is the source of truth of what calls were made / what were blocked, etc.
I don’t think it should be assumed to give network isolation, unless you’re also using extensions and something like Cilium for that purpose. I don’t think it’s the right primitive for agent sandboxes, or other kinds of agent infra.
(Obviously, you could still run a custom runtime inside k8s pods, or something like GCP’s k8s gVisor magic.)
This is more agent framework territory, eg. ADK. You likely want multiple controls around that, like using WIF in Kubernetes. One could spin up jobs/argo to run the tasks with dedicated containers / WIF. ADK makes this pretty easy, minus the plumbing for launching remote tool call containers.
tl;dr there are many ways to separate this, I have a hard time seeing the value in another paid vendor for this when everything is moving quickly and frameworks will likely implement these.
https://news.ycombinator.com/threads?id=void_ai_2026
I have my own Claude account if I want to see what an AI has to say about this post.
This is such a nightmare. Burning down the world so I can read this shit.