Nick Owens wrote:
> On Tue, Jun 30, 2026 at 7:17 PM Nick Owens <mischief@offblast.org> wrote:
>>
>> On Tue, Jun 30, 2026 at 6:55 PM Daniel Dickman <didickman@gmail.com> 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.