On Fri, Jul 3, 2026 at 11:40 AM David Uhden Collado <[email protected]> wrote: > > Nick Owens wrote: > > On Tue, Jun 30, 2026 at 7:17 PM Nick Owens <[email protected]> wrote: > >> > >> On Tue, Jun 30, 2026 at 6:55 PM Daniel Dickman <[email protected]> wrote: > >>> > >>> > >>> > >>> On Wed, 1 Jul 2026, David Uhden Collado wrote: > >>> > >>> Hi David, thanks for taking a look. > >>> > >>>> Are there any plans to port opencode to OpenBSD as well? From a > >>>> maintenance > >>>> perspective, it seems like one of the more useful candidates because it > >>>> supports models from many different providers instead of being tied to a > >>>> single vendor. > >>> > >>> No I have no plans, but there's nothing stopping someone that wants to > >>> tackle it. As I'm sure you're aware there's some history between opencode > >>> and crush. > >> > >> there is absolutely something stopping someone from porting opencode. > >> opencode depends on bun, and for reasons that only mac users and > >> javascript programmers understand, bun depends on bun now to build. > >> bun does not work on any of the BSDs, and the effort to do the freebsd > >> port upstream prior to this situation got dropped. as far as i can > >> tell there is no plan by upstream to fix this. > > > > i'm going to yolo shoot this to the wind, to see if there's any bites. > > > > i was intensely frustrated by the situation with bun, giant nodejs, go > > and python programs, and necessity is the mother of all invention so i > > vibe coded an agent library and tui in c that has pretty basic deps > > and i have confirmed it runs on openbsd (at least at some point, it's > > moving fast). i've also got an unpublished port to esp32, and > > hopefully soon i will try omnios (solaris) to verify portability. > > > > for openbsd specifically, i have used it on openbsd 7.9 with the > > dependencies from packages, and i have confirmed it works with > > kirill's llama.cpp using some downloadable models from huggingface on > > my thinkpad a485. > > > > this is barebones and very new, but i would be absolutely ecstatic if > > there was any interest in it. that said, with the advent of coding > > agents, code is cheap. it's not hard to reproduce, but the human touch > > is the thing they do not capture. > > > > check it out at https://github.com/mischief/clm :-) no refunds. > > > >> > >>> > >>> crush supports many providers. (fire it up and the first prompt is to pick > >>> your favourite provider). swival also supports many providers, but is a > >>> more specialized agent. > >>> > >>> I have sent the ones that would be useful to me (codex is already in ports > >>> and I use it too). > >>> > >>>> > >>>> My concern is that importing many AI-agent CLIs could become expensive to > >>>> maintain. > >>> > >>> I've put myself down as maintainer, I don't think it's very much burden to > >>> be honest. > >>> > >>> claude will be frozen in time and can't be updated given the > >>> discontinuation of the npm distribution. > >>> > >>> swival is mostly python which I can easily keep up with and crush is > >>> self-contained go code. > >>> > Hi Nick, > > Thanks for sharing this. I really like the project, especially the focus > on portability and keeping the dependency stack small enough that it can > realistically run on OpenBSD and other non-mainstream systems. That is > exactly the kind of direction I would like to see more of. > > What I am mainly looking for, though, is something closer to: put in an > API key and then work with almost any provider. For example, I like > DeepSeek a lot because the models are open-weights and the API is very > cheap, so being able to use providers like that directly is important to me. > > Local llama.cpp support is definitely useful, and I appreciate the > OpenBSD angle, but my main interest in tools like opencode is the > provider-agnostic workflow: one CLI or agent interface, many backends, > without being locked into a single vendor or model source. > > So I am very interested in the portability side of clm, but for my use > case the big missing piece would be broad API-provider support.
i have already tested openai, huggingface, even github models to varying degrees of success with the API keys via CLM_API_KEY env var. llama.cpp is just the easiest target since i have available local gpu and cpu compute that can run somewhat reasonably run 9b-35b models with q4-q8 quantization. in my recent experiment i made it drive games/cataclysm-dda by adding a rest server into the game and constructing a (lua) tool that can get game state and take actions, but when i pointed clm at the paid OpenAI API, it ate my $20 in about 5 minutes. so.. yes, i am going to keep using llama.cpp for development for now, but it does work for paid APIs for SOTA models, but they aren't cheap. as far as broad support API goes, just look if they support OpenAI API. if so, that's what's supported right now. adding something else isn't really that complicated either. if there is something specific you can name, i can try to test it and support it. thanks for the feedback :-) > > Best, > David.
