Live data from Hacker News

Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

news.ycombinator.com

81–90 of 95 posts

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#81

Earlier quoted context omitted.

Ha, real human here! I'm a Chinese developer. I composed the question myself in Chinese and had AI translate it to English, hence the em dashes. The underlying curiosity about inter-agent auditability is genuinely mine though.

A polite request: English and Chinese are very different languages, asking AI to "translate" your thoughts sanitizes what you have to say, your words lose all of your personality -- a great shame. Participation from non-English speakers is wonderful but rather than use AI to "translate", using a literal translator (e.g: Google Translate, DeepL) will ensure we get to hear what you have to say, not what AI thinks you w…

That's actually a quite rude and condescending request.

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#82

is this a replacement to langgraph?

Depends on your agent. We haven't used langgraph, but I'd think it's probably the best solution to deploy langchain agents. We're SDK agnostic. We're like langgraph, but for agents that works in a sandbox and needs access to a filesystem to do work.

ok. how is this different from openclaw?

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#83

Earlier quoted context omitted.

A polite request: English and Chinese are very different languages, asking AI to "translate" your thoughts sanitizes what you have to say, your words lose all of your personality -- a great shame. Participation from non-English speakers is wonderful but rather than use AI to "translate", using a literal translator (e.g: Google Translate, DeepL) will ensure we get to hear what you have to say, not what AI thinks you w…

That's actually a quite rude and condescending request.

How so?

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#84

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?

You can use the default Claude Code harness with Claude Agent SDK (just set the prompt preset to claude code). Same with Codex.

Would this yield exactly the same behavior when thinking about sub-agents and all this functionality?

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#86

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 m…

[dead]

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#87
post #38

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 ba…

That's a good analysis:) We want to go with FUSE but the performance overhead, especially with multiple calls to use files, is a constraint

How have you determined that? You can easily push 6GB/s+, sub ms ttfb with networked filesystems, and hundreds of thousands of iops through fuse.

Re: Launch HN: Terminal Use (YC W26) – Vercel for filesystem-based agents

#88
post #2

Can you explain why everyone thinks we should use new tools to deploy agents instead of our existing infra? eg. I already run Kubernetes

There are a lot of reasons for this, but typically “same same reason you would use k8s for customer serverless functions”: can’t scale fast enough, too slow to place workloads, not isolated by default, configuration explosion, limited multitenancy support, and so much more
Post reply on HN