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?
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.
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!
I think Kubernetes is a good candidate to run these sandboxes. It is just that you have to do a lot of annotations, node group management, pod security policies, etc., to name a few.
Apply the principle of least privilege for access to mitigate risk.
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.
I think there are some primitives for agents that need to be built out for better security and being able to reason about them.
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.
Unrelated but your comments on https://news.ycombinator.com/item?id=44736176 related to the Terminal agents coding craze have helped me feel less crazy. People using GitHub Copilot CLI and Claude Code, they either never review the code or end up opening up an IDE to review the code, and I'm sitting here like, why don't you use the terminal in your favorite IDE? You're using a Terminal as a chat interface, so why not just use a chat interface? Or use the terminal in VS Code which actually now integrates very well with Claude Code and GitHub Copilot CLI so you can see what's going on across the many files this thing is editing?
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.
Glad to find comradery! I've started the CLI interface to my custom agent since lol
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)
We have also built something custom ourselves (with modal.com serverless containers), running thousands of on-demand coding agents each day and already the assumptions that Terminal Use is making (about using the file system and coding agent support) would not work for our use case.
It seems like so many of the AI "solutions" are hallucinating the problems. I either don't have them, because I use better AI frameworks, or I have tools at hand that solve them nicely.
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.
At least on K8s you can control the network policy. That's the harder problem to solve. I suspect we'll see a lot of exfiltration via prompt injection in the next few years.
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?
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.
howdy! two things on the archil front:
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!
I'm using Dagger to checkpoint and all the fun stuff that can come after
Can you explain why everyone thinks we should use new tools to deploy agents instead of our existing infra?
eg. I already run Kubernetes
I think Kubernetes is a good candidate to run these sandboxes. It is just that you have to do a lot of annotations, node group management, pod security policies, etc., to name a few. Apply the principle of least privilege for access to mitigate risk.
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
I think there are some primitives for agents that need to be built out for better security and being able to reason about them.
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.
Unrelated but your comments on https://news.ycombinator.com/item?id=44736176 related to the Terminal agents coding craze have helped me feel less crazy. People using GitHub Copilot CLI and Claude Code, they either never review the code or end up opening up an IDE to review the code, and I'm sitting here like, why don't you use the terminal in your favorite IDE? You're using a Terminal as a chat interface, so why not just use a chat interface? Or use the terminal in VS Code which actually now integrates very well with Claude Code and GitHub Copilot CLI so you can see what's going on across the many files this thing is editing?
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.
Glad to find comradery! I've started the CLI interface to my custom agent since lol
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)
We have also built something custom ourselves (with modal.com serverless containers), running thousands of on-demand coding agents each day and already the assumptions that Terminal Use is making (about using the file system and coding agent support) would not work for our use case.
It seems like so many of the AI "solutions" are hallucinating the problems. I either don't have them, because I use better AI frameworks, or I have tools at hand that solve them nicely.
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.
At least on K8s you can control the network policy. That's the harder problem to solve. I suspect we'll see a lot of exfiltration via prompt injection in the next few years.