tldr free, no api key needed, just curl bash and then have it help you set up your vm or fix a harness etc. think of this as a primitive harness that helps you bootstrap stuff. the long term hope is that most future unix like systems ship with something like an “llm” command. you have vi or nano on most systems, out of the box. curl and so on. so one day “llm” where you boot up and you have a basic, free, minimalist terminal harness that can bootstrap your system for you. it doesn’t need to be an erudite complex llm, but just a basic one that can do the basics. that’s the vision i have.

it’s completely free. the use case is if you have a fresh vm and want to skip having to type a bunch of apt install commands / setting up gh and so on. or if you have say opencode or pi but you broke your config. now you have a model that can help bail you out and repair stuff. no api key, it just uses a shared pool of free llms via open router. it’s basically a free minimalist coding harness with free llms to help “bailout” a bad config or a fresh vm into something more useable.

nice, not dissimilar to what i built for https://github.com/storozhenko98/beehive

I'd suggest adding a few screenshots on the Github README, otherwise I wouldn't have enough attention to imagine how it looks. I had to go to the website to appreciate your work, otherwise I'm like "what is it?"

time to ask AI what the best features in yours and Ops are and then merge them into my also similar project .

This is so cool

Yeah probably. Then again, opencode is not provider-specific && I prefer it to claude code (though I do use CC for personal stuff outside work because $$) and I missed their zen black or whatever the opencode $200 is.

My dream is a more indie world, so I'm glad to see you building too.

But we don't all need to share our personal, custom agent setups like we are going to be the new sliced bread. I have my own, I think it's great and better than most out there, but I'm not going to Show HN it amidst the Claw HN submissions, if ever. I generally link to interesting pieces in comments when someone asks how I implement a particular feature.

My custom agent setup is a component in a larger developer "swiss army knife" I have been building for 8ish years. Same handle on github if your are curious, project is "hof" with a rename imminent.

The agent part is built on ADK, which I believe is relatively on par with opencode, which I also see is highly regarded. The multi-workspace feature is built on Dagger and the VS Code virtualized FS and SCM interfaces. I can browse or get a diff at any turn-to-turn span, make edits that go right back in.

This is not a helpful comment, please see the Guidelines linked at the bottom of the page.

Yeah, the idea is that you set up a repo for a project (the hive), and then once you have the hive, you can set up multiple combs (git clones, not workspaces) and work in parallel. Suppose you have like 3-5 issues / tickets you're working on - the idea is that you can do this in parallel, in isolated dirs, and jump between them in one place. I used to have to do this in tabs in zellij / sessions in tmux and remember which sessions is which issue / ticket. Also having to manually git clone everytime was annoying. So this is an abstraction to simplify this. Does that make sense?

I think it's making sense. Many of my workflows involve e.g. multiple different repos that house different parts of something (e.g. deployment automation is over here, application itself is over there, sometimes a change needs to happen to both at once). I find myself having to work serially on tickets because two different issues might touch the same repos and so I manually maintain branches and switch around between them; this adds starting friction to my work.

Ah, if in different repos that would map to different hives, so that would require switching between hives in the top left drop down. Still persistent, but not as streamlined as clones within the same repo / combs in same hive. I have been spoiled (?) by monorepos so that's why designed for this.

> I have been spoiled (?) by monorepos so that's why designed for this.

I too find monorepos superior at this point in time. There are essentially the same complexities both ways (polyrepo), two sides of the same coin. I have broken slightly, having "megarepos", where most code is in one place, but a few are broken out, possibly another "megarepo". The most natural split is public vs private.

Conway's Law: repo structures reflect team structures and permissions mapping.

Oh this is great, did not know about this but going to check it out. I like that it also has a little git thing on the right. Thank you for sharing this.

Point taken