Hacker News

Based on the docs and API surface, I think the filesystem abstraction is probably copy-on-mount backed by object storage.

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.

Really interesting platform — the decoupled filesystem model makes a lot of sense for long-running agents.

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.

Congrats on launch! As the agent cli’s and sdk’s were built for local use, there’s a ton of this infra work to run these agents in production. Genuinely excited for this space to mature.

I have been building an OSS self-hostable agent infra suite at https://ash-cloud.ai

Happy to trade notes sometime!

This is really interesting, congrats on the launch. The use case I’m trying to solve for is building a coding agent platform that reliably sets up our development stack well. Few questions! In my case, I’m trying to build a one-shot coding agent platform that nicely spins up a docker-in-docker Supabase environment, runs a NextJS app, and durably listens to CI and iterates.

1) Can I use this with my ChatGPT pro or Claude max subscription? 2)

> We built Terminal Use to make it easier to deploy agents that work in a sandboxed environment and need filesystems to do work.

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?

The version pinning approach for existing tasks is a pattern I've found really useful in practice. When you're building document processing workflows (transcripts, reports, etc.) the ability to iterate on your agent logic without retroactively breaking existing user sessions is underrated.

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.

I'm currently using them to build an AI agent similar to lovable/replit-esq in tech stack and it works.

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.

We've been running filesystem-based agents internally at heyvid for about six months now, and the deployment story has honestly been the messiest part. You end up hand-rolling so much scaffolding that's not your core product. The 'Vercel for agents' framing clicks immediately — I remember when Vercel did the same thing for frontend and it just removed a whole category of yak-shaving. Curious how Terminal Use handles state persistence across runs; that's been our biggest headache when agents need to resume mid-task.

The filesystem-as-first-class-primitive approach is interesting. I've been building MCP servers (Model Context Protocol) for infrastructure management — letting AI assistants interact with Proxmox clusters, ClickHouse databases, etc. — and the hardest part isn't the agent logic itself, it's the lifecycle around it: state persistence, deployment, and making sure the agent can't accidentally destroy things.

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?

There clearly needs to be something in this space, but I can't imagine the world standardizing on a closed source system for this infra.

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.

have you guys found any of the existing nfs tools helpful (archil, daytona volumes, ...) or did you have to roll your own? i guess i have the same question for checkpointing/retrying too. it feels like the market of tools is very up in the air right now.

Im curious if you guys are seeing rate limiting issues. Agents sharing api keys tend to be retry storm monsters. I wonder how agent companies will address

When building, did you not have the thought or feeling that you would prefer the actual Claude Code and Codex harness to run, rather than just the SDKs also for your Agents?

how does it compare to https://shellbox.dev? (and others like exe.dev, sprites.dev, and blaxel.ai)

Hmm.. so this is not the same category with computer use or browser use. I love the idea. Well defined and controlled sandbox is really useful. Off topic but I’m disappointed by computer use and browser use when I tried three months ago. They couldn’t complete many basic tasks. Especially browser use, it easily failed slightly unorthodox website. It can’t find select box implemented by div, stacks in infinite loop when the submit button is disabled, and it even failed to complete the demo in its own readme! I’m okay with open source projects a bit buggy, but a VC funded company, which already has the fancy landing page, provides the service to big corps, and offers paid plans, should at least make sure the demo works.

is this a replacement to langgraph?

Can you explain why everyone thinks we should use new tools to deploy agents instead of our existing infra?

eg. I already run Kubernetes