From: David Uhden Collado <daviduhden@gmail.com>
Subject: Re: [NEW] 3 AI coding agents: claude, crush & and swival (+ deps)
To: didickman@gmail.com, ports@openbsd.org
Date: Wed, 1 Jul 2026 01:32:00 +0000

Daniel Dickman wrote:
> Hi all,
> 
> I'd like to import 3 AI coding agents that I've found useful. (Similar to
> devel/codex which is from OpenAI and is already in the ports tree).
> 
> 
> (1) devel/claude -- Anthropic's well known coding agent
> 
> 	This is the latest version that runs on OpenBSD. Newer versions
> 	were moved off npm and are native-only unfortunately. So updating
> 	beyond this version might be harder.
> 
> 
> (2) devel/crush
> 
> 	A coding agent with a focus on a good looking
> 	terminal UI.
> 
> 
> (3) devel/swival -- Coding agent for doing security audits
> 
> 	This has has a few additional dependencies that also need to be
> 	imported below.
> 
>      devel/py-litellm -- uniform LLM provider API
>          textproc/py-tiktoken -- fast BPE tokenizer
>      devel/py-mcp -- Model Context Protocol SDK
>      security/py-fast-cipher -- fast AES cipher library
>      textproc/py-rank-bm25 -- BM25 ranking functions
> 
> 
> One small note is that for swival to be imported we also need to update
> py-rich to 15.0.0 and mark www/py-flask-limiter BROKEN as a result.
> 
> In turn this means we won't be able to build www/py-flask-appbuilder until
> flask-limiter adds support for rich v15+.
> 
> I am ok with that tradeoff (I imported those 2 ports for superset which
> itself is waiting on support for sqlalchemy 2+ to be rolled out).
> 
> ok to import these new ports?
Hi Daniel,

Thanks for working on these ports.

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.

My concern is that importing many AI-agent CLIs could become expensive 
to maintain. These tools change very quickly, and in practice ports can 
take a while to catch up when the maintainer does not have direct commit 
access or when updates require repeated reviews.

This is not an objection to the imports you proposed. I just wonder 
whether it would make sense to prioritize one provider-agnostic tool 
like opencode, since that could cover more use cases with less long-term 
maintenance burden.

Best,
David.