I also quite like that it has a decent CLI and skill for agents to use too.
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.
I remember in the early days when I was just trying out ChatGPT on a phone for the first time (this was around GPT-3.5? GPT-4o?) and snapping a picture of our fridge that's full of magnet souvenirs and asked it to identify all the places we've been in and it gave a nice list of what it saw and the places that were featured.
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.
why do I feel like they basically added their AI support chatbot to the same group / mailing list that the human support belonged to along with the same permissions set and just called it a day?
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.
The thing that intrigues me on this one is the Opencode roots.
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.
Surprisingly, there's a lot of items I'm seeing at first glance here at Odysseus that open-webui either doesn't have or takes extra effort to add in and I've used the latter for a really long time already.
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.
This is three steps back, one step forward kind of an approach imho.
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.
That's a correct example, and I agree, it is disingenuous to just trivially call this an `is-odd` project.
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.
I've been using it and so far yeah, a lot of the existing functionality and new functionality is effectively free and it generally only nags you when you use the clearly separate "Canva AI" panel.
Checking the settings also tells me that Segmentation (used in Object Selection) is provided but Depth Estimation (used in Portrait Blur and Select Sampled Depth tools), Colorization (used in Colorize filter, apparently intended to colorize B&W photos) and Super Resolution (used in Super Resolve filter) are all paywalled.
Honestly, I think that's fine. While I'd wish these are all available (and they could be if you looked hard enough for models that can do this) for a flat price (for parts that are not handled server-side), this is still imho mostly fair.
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)