Video yükleniyor...
Video Yüklenemedi
Coding agents shouldn't run on a laptop. That's why I've been building Cave. It's a self-hosted platform for running OpenCode agents in isolated sandboxes on your own server. You give it a GitHub repo, it creates an isolated sandbox, clones the code, sets everything up, and gives you a... show more
36,142 görüntüleme • 5 ay önce •via X (Twitter)
46 Yorum
y no open source? if you want an open source project that is shipped in production across multiple teams with no waitlist supports - multiplayer sessions - slack, web, linear, github - integrated GH code reviewer - tunnel ports - code server and more!
You can find more information about the project here:
@opencode Very cool, don't need open source, just something that works lol 😆
@opencode looks cool!
@opencode I'm interested in this!
@opencode Running agents in isolated sandboxes on your own server feels like the right default. Once teams go beyond one laptop, the real need is observability across runs, repos, and permissions, not just a better local loop.
@opencode brilliant work playing with cave today, would be cool if you oss it :) let's launch you on btw anytime helpful
@opencode been thinking about this a lot. we built around the same idea, VMs that boot in milliseconds so agents get their own isolated compute. the laptop bottleneck is real
@opencode Hii Im interestedddd
@opencode sending you a DM!
@opencode Looks super interesting! We have a multi-repo use case (like what Warp’s Oz supports, where when you create an agent session, you can add multiple repos). Is that something that could perhaps be supported (or already is)?
@opencode It is already supported. You're starting a Cave with one repository, but you can do in the Cave whatever you want (e.g. cloning additional repositories).
@opencode Self hosted is the right direction for coding agents. Once runs move off laptops, the real differentiator becomes isolation, traceability, and how easily teams can monitor multiple parallel agents across repos. Cave sounds like it is aiming at the right bottlenecks.
@opencode This sounds cool! I have been building Maestro because I wanted code on the road. It’s just sandbox terminals but maybe that’s interesting as well :)
@opencode The isolation model makes a lot of sense. One agent nuking your env files is funny once, not twice.
@opencode Hi, I'm interested! I currently use emdesh as a harness harness, but am not happy with their performance and am looking for solutions to ssh into my remote dev environment but still being able to keep the overview of different agents across different projects
@opencode 👀
@anmol_soin @opencode Why opencode
@anmol_soin @opencode Multiple reasons, but the most important one: It is awesome 😬 Then, the architecture is a great fit, supports all LLM providers out there, etc. OpenCode comes pre-installed. You can install whatever harness you want within your Cave though.
@opencode isolated sandboxes is the right call. I've had agents accidentally delete test fixtures, overwrite env files, even mess with git history on the main branch. running them on my actual dev machine stopped being acceptable after the third incident.
awesome, yeah I've been using opencode and hosting it on a ovh server. One of my projects involves a lot of cuda work so I've also been using vastai. That was a huge mess at first but I've got a really pretty hacky solution that actually works fairly well barring network or tool problems. I had to write a basic local http server(with an openAI proxy) and a coordinator/message endpoint, install opencode on the remote machine, and then start the opencode server. I then tunneled that port to the ovh server and tunneled the coordinator's port to the instance. Each remote instance is started via ssh and using --attach to attach it to the opencode server and --format json which outputs the raw json events. That is recorded to a jsonl log file for a given session id. Its a huge mess because its a fundamentally different use case than opencode was designed for. Trying to attach 8 instances to the server on ovh just kills it and there is no reason for that imho. Javascript on that server should be able to handle several thousand connections at once and 8 shouldn't even move the needle. My next project after this is going to be similar to opencode but drastically simplified and with a hub-spoke pattern where the spokes are envs and the hub coordinates between llm providers and the tools for the envs. There is just no way it should kill a server with even several hundred or maybe a couple thousand running at once since its just basically proxying between providers and tool calls with some added overhead for logging, permissions, etc - less than the overhead from a typical full stack app.
@opencode 🔥
@opencode This recorded with openscreen?
@opencode Well done. I've been building something in a similar spirit (which I won't share here to steal the limelight!) so I appreciate the thoughtfulness into the details. Installing Cave as i write this!
@opencode I'd like to try this on a Pi 4b
@opencode Technically it should work. Didn't try on a RPi. Drop me a DM and give it a spin ☺️
@opencode lmk when oss
@opencode any chance gitlab can be included? :) not every repo runs at github :c
@opencode You’re right, GitLab isn’t on the immediate roadmap though.
@opencode 🥺
@opencode exactly. we're solving this at - VM boots in ~1 second, you get a live computer on the internet. agents run there, not on your machine. no deploy step
@opencode exactly right. the laptop-as-compute model breaks the moment you want the agent running overnight. we built for this, SSH into a real VM in under 1s, fork state mid-run, suspend without losing anything. no docker wrappers, own kernel
@opencode So it's essentially conductor right? Good work.
@opencode Would love to take it for a spin
@opencode The interesting shift is from “give every agent a terminal” to “give every workflow an execution surface with isolation, lifecycle, and observability.” Once you run multiple agents in parallel, laptop-local stops being a serious control plane.
@opencode we built for this exact use case. managed cloud computers with fork - branch a machine per agent, run in parallel, destroy when done. sub-10ms suspend, persistent disk, Claude Code pre-installed
@opencode Hate to ask but don’t you just need one opencode server for this vs many?
@opencode You wouldn't have any kind of isolation between the projects then. One OpenCode server would maintain multiple projects then. One Cave = one project with a strict isolation.
@DerekBarrera @opencode how strict? VMs? Containerization?
@DerekBarrera @opencode Currently Incus containers with Kernel Livepatch, but the architecture is swappable. Working on an adapter for Firecracker. Others adapters for existing sandbox solutions is on the roadmap.
@opencode I hope there will be a file manager.
@opencode Yes, I'm working on extension points so that there will be a plugin (eventually) that provides a file browser. In the meantime you can connect to your Cave with VS Code / Zed and use the file browsing capabilities from there.
@opencode Want $10k credits to try sandboxes?
@opencode Opencode are working on orchestration and managing multiple servers from one opencode and also actively working on multiple sandbox provider support. Is there something different here? Not sure how this can become a paid product when a free alternative exists
Who said that it needs to become a paid product? The harness and the sandboxing story is one aspect. My idea for Cave is exploring the possibilities of "what an IDE of the future" could look like. I want to tackle problems like: workflow orchestration, context streamlining, building extension points so that you can easily extend it in a way that matches your own workflow, etc.
@opencode Ah ok! That explains it better! Sounds exciting
