So far, "OpenCode" has gone through several possible definitions:

- OpenCode Terminal / CLI - This is what you get normally. Runs a service in the background and the CLI is your interface.

- OpenCode Desktop - Instead of a CLI, you get a desktop interface.

Most users usually stop here. You just install the app and you connect wherever.

So there's the services where they both make money and make things easier for users:

- OpenCode Console - Basically the serving platform for both Zen and Go, and has expanded to a hosted inference gateway and somewhat similar to OpenRouter or a managed LiteLLM. Has the option to BYOK if you have existing AI platform accounts so it charges those instead of Zen, and that's what got compromised.

- OpenCode Zen - the API service they host if you want to get access to providers but don't want to pay individually per API platform. Similar to OpenRouter. I noticed they're kinda slowly dropping the Zen moniker.

- OpenCode Go - the subscription service that they host that features open weight models and select low-cost models from frontier labs. Has different policies when it comes to privacy and retention compared to Zen.

- OpenCode Black - a limited-time, limited access subscription service that grants access to frontier models. Not sure if this is still alive or not.

But ever since I've switched to one of the $100-tier subs, I can see why a lot of the people on it don't really discuss the open models often. I'd still use it especially when it comes to sensitive inputs, but for most work, what you get on OpenAI or Anthropic is really more than enough.

It really got even better when they also made their cheaper models up to par if not better than the open models.

I do think the crowd for open models are out there, especially when you see trillions of tokens running for them on OpenCode or OpenRouter leaderboards.

Thanks for the tips. TIL about BTT having MCP support. Crank looks very promising too, since it looks like a more effective Shortcuts and Hazel replacement

I agree, I don't think people are going to remotely pair-prog with this when it's existed in the past and most work on their own and let their pull requests do the talking.

But I say non-code and planning because I've definitely strategized with AI before and have scrapped a good chunk of it because I overlooked details that my team shared. Being able to get that on an active session with context shared across all members as it's debated sounds good and would've reduced turnaround time.

I remember the Opencode folks mention about gangprompting before and I guess this is one take of it, besides adding an Opencode bot on Slack and hoping that's competent enough for the work that needs doing. I've never tried it myself, so I'm not gonna criticize it, but I'm sure it's an idea people want to see if it's effective.

Herdr holds potential in stuff like their socket API ( https://herdr.dev/docs/socket-api/ ) and whatever enhancements they wish to bring (e.g., https://herdr.dev/docs/agent-automation/ ) so if that appeals to others, it's worth a shot.

But for most regular users, tmux and other multiplexers work just fine.

Realistically, what I use about its agent stuff is:

- reliable notification pings either via what your terminal app uses (e.g., ghostty's) or system or just within herdr only

- if absolutely necessary, be able to tell agent sessions to observe and run commands on a herdr pane (security beware, for obvious reasons)

- herdr --remote which is basically a quick SSH -> attach to herdr on a remote

- prefix+g (equivalent to prefix+w in tmux) presents itself nicer, has binds for agent state filtering and its /search imho is mildly nicer than tmux's

Arguably, you can have the same points in others if you know how to configure tmux or zellij already, so if you're comfortable with that then you really don't have to use herdr.

Or even if it's similar, it's still clearly staged to look more appealing than what you should be getting.

Everyone knows deceptive advertising is bad, but somehow those who use AI for advertising turned their brains off on this topic because the images looked cooler than what they'd normally produce with a camera.

Logitech did something similar if I recall right.

Will definitely check this out since it sounds like it eases through the pain of dealing with these.

Quite handy to apply since you can instruct models to run devservers in herdr panes or workspaces rather than doing long running shell commands or scripts in the agent session.

(You could probably do the same with tmux and others but I've had better success with monitoring herdr state)

A few years ago, I started moving towards Podman when it got to that "good enough" point on both Linux and macOS and when Docker started to remind people about Docker Desktop that it needed a license for commercial use.

Even then, it took around a year or so to transition.

To some degree, the closest we have to these situations besides getting flagged with TOS violations (whether real or false-flagged) in these companies are residents of countries that are either trade or economically sanctioned by the USA.

Thankfully we haven't seen something like an account ban and deletion incident for such cases, but the severe ones I can remember usually prohibit access entirely and that'd be scary if it extended to primary services that others rely on for auth.

You will be effectively locked out to services if it's all that's linked and that identity provider just decided you'd be persona non grata.

Did it get it fully right? No. But it was one of those "oh wow, you could do that?" moments for me. There's obviously a lot more "oh shit" moments as time went on, but it was a neat little moment.

I'll laugh even harder if they wrote tests for it and only made tests for the happy path and not the error cases or just ignored the latter.

I've currently host both Open WebUI and Opencode on a server setup and there's multiple things that Open WebUI has implemented very nicely over time but it was also prior to the emergence of coding agents / harnesses. As such, its strengths is more on the `/chat/completions` era and RAG and its own functions and ecosystem setup before tool calls were a thing.

If this stuff works for you already, I think that's fine. That's not a bad thing, and if anything, they've made attempts to improve esp. with the recent backend upgrades and projects like `open-terminal`.

However, Opencode has been built for the coding agent setup since its early days and Odysseus gives me more confidence to run sessions much better knowing that it runs on an Opencode core.

Stuff like MCP support and a clearer lifecycle for example are things I've never really seen implemented well on open-webui (they've improved and support this now, but I'm biased and am salty of the era from its early days of MCP support when they insisted you place a bridge (mcpo) in between just to make it do MCP.). In contrast, opencode does this very well since what they built that works on the terminal also applies to the desktop app and the ACP support for IDEs that use it to connect to the opencode harness.

At the minimum, I expect Opencode to work wonderfully against the frontier models, and all models they host on their Zen and Go service, so that adds some confidence as well on complex workflows.

In contrast, I still find model management a pain in the ass on open-webui (has always relied on LiteLLM or a third-party inference gateway) just to wrangle the models. Hell, they still tag the Responses API "experimental" today, a format that's been around since over last year.

Does that transfer to Odysseus? Maybe, maybe not. Seems it's based on it but a quick check on code says they merely adapted it so maybe it's the latter. I haven't tried it at depth and idk how well Pewds has implemented it, but if it improves on that angle and gets maintainers that accepts contributions from the community, I feel like it'll do nicely.

Stuff like an agent mode, deep research and document work are things you'd be able to have with open-webui as well but Odysseus seems to have them thought out.

Easy for everyday users to deal with, and effective for verifying humans vs bots.

But holy hell, if your phone is a requirement to access sites and you have to go through the security theater like a work device and setting this behavior as a default assumption to have? Ugh. The privacy and security implications of this is quite ugly to think about too, now that Google can link your devices to a stronger degree with this approach.

The lines drawn by their consumer vs commercial TOS was clear and I never subscribed because of it.

Back in the days of GPT-3.5, LiteLLM was one of the projects that helped provide a reliable adapter for projects to communicate across AI labs' APIs and when things drifted ever so slightly despite being an "OpenAI-compatible API", LiteLLM made it much easier for developers to use it rather than reinventing and debugging such nuances.

Nowadays, that gateway of theirs isn't also just a funnel for centralizing API calls but it also serves other purposes, like putting guardrails consistently across all connections, tracking key spend on tokens, dispensing keys without having to do so on the main platforms, etc.

There's also more to just LiteLLM being an inference gateway too, it's also a package used by other projects. If you had a project that needed to support multiple endpoints as fallback, there's a chance LiteLLM's empowering that.

Hence, supply chain attack. The GitHub issue literally has mentions all over other projects because they're urged to pin to safe versions since they rely on it.