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.
Best,
David.
