GLM 5.3 and all previous models don't have a vision encoder and can only accept text. Ox-Alpha can accept video and images, so unless Z-ai added a pretty good vision encoder for this model, I don't think so.
My money is on Moonshot and this being Kimi K3.5. The measured tps and latency is in-line with K3's tps and latency from Moonshot.
MiniMax M3.5 is also possible (but the MiniiMax provider is a lot more performant than the lab behind ox-alpha, so less likely).
The other tell from the provider angle is capacity. Whoever is hosting Ox Alpha has a lot of capacity which narrows down a lot of the Chinese companies.
DeepSeek literally just came out with the vision-enabled version of Flash v4 which was purely text based. Why would GLM not be able to do the same thing?
I hope this is not Kimi K3.5 because it really sucks. It is very slow, not particularly smart when it comes to coding, and easily starts going in circles - when not straight up going into a doom loop.
Z.ai founders were one of the pioneers in MM-LLMs with Cog-VLM years ago, back when LLaVA emerged. I wouldn't be surprised if they added multi-modal capabilities
> a lot of apps run 100% of traffic through openrouter while for us it's a small subset
> but companies we were trying to work with used openrouter as a source of truth on popularity so they thought products that were much smaller were bigger than us
> How you deal with LSP? One of the best things in OpenCode is LSP integration.
I would love to learn how LSP helps you. I did various basic evals with LSP and I did not find it to improve the agent performance at all. Maybe on newer models this gets better because they are now RLing with LSP in the context, but at least in the past having a commit hook that runs lints and typecheck at the end, is more token efficient than having every edit be injected extra LSP results. You are almost guaranteed to be wasting tokens since partial edits are unlikely going to result in type checks passing.
It's for using lsp to do things like symbol renames. It's cheaper to call an LSP server to do those kind of simple refactors than to spend tokens on the model doing it.
It can also use LSP to build context without having to grep around a ton. You don't have to grep and hten pull lines and make guesses for a function. You just ask the LSP for it.
How helpful all that is is heavily dependent on the quality of the language server so usefulness is varies wildly between languages
> It's for using lsp to do things like symbol renames. It's cheaper to call an LSP server to do those kind of simple refactors than to spend tokens on the model doing it.
Is OpenCode pushing the LLM into doing these refactors via LSP? I found that making these refactors with ast-grep is quite efficient.
> It can also use LSP to build context without having to grep around a ton. You don't have to grep and hten pull lines and make guesses for a function. You just ask the LSP for it.
I guess I was not particularly successful with having the agent actually do that. I think what fff is attempting to do (with fuzzy expansion of slightly inaccurate greps) results in better results to me, but even that is debatable.
To be fair, we do not have evals for this today, but we're generally looking into token efficiency and how likely models are at using tools the right way, and we did not find a ton of evidence of LSP helping, even for finding data.
But I would love to see some sessions from people where they have success with LSP data for either refactoring or looking up, because this would be super useful to better understand out blind spots.
To be fair in every harness I've ever used that has LSP support, they never actually utilize the LSP for more deterministic refactoring tools. And even then when I do enable the LSP in many harnesses oftentimes it doesn't even use it at all.
Maybe they haven't been taught to do so or it's not integrated into the system prompt or the tools but all of them only ever use the LSP to read files/symbols.
Every harness I've used will happily just call the edit tool over and over or do a find and replace via sed or programatically call a python/perl script rather than rename a symbol via other means.
This is partially a "how much does the model follow instructions" thing. I use Pi with a vibed LSP extension and Claude (4.6 or thereabouts) almost never followed instructions to use LSP renaming tools - despite it being strongly emphasized in system prompt and agents.md. However I found Codex 5.3 would use them sometimes, and GPT 5.4/5.5 would prefer them.
It sounds a lot like you are focused on using Pi as a OpenAI/Anthropic wrapper when that isn’t your audience. (Hint: raw token usage is less of a concern).
Oh My Pi has it. I'm a big OMP shill right now. Seems not very popular, but it has the stability of Pi with the features Opencode (and more I think; OMP has web browsing and a more advanced edit system too). OMP often outperforms Claude Code and Codex for me.
I disliked OpenCode's LSP integration, as Pyright kept distracting the model from what I wanted done in a Django project. I prefer to run MyPy at my own convenience
I use a forked version of the pi-lsp. It works pretty well out of the box, but I just tend to fork extensions by default and then hack them up how i see fit.
I purged OpenCode when I noticed it downloads npm packages in the background without asking the users first. This exposes higher risk of supply chain attach risk.
> Having come from Claude code, I was a bit shocked that both seem to allow edits by default with no confirmation dialog.
There are confirmation dialogs in OpenCode. You can configure them using the permission config, same as Claude Code. Having said that, as a general rule, none of these harnesses are safe to run on your local file system.
I wonder if that's a recent change. When I first started using OpenCode, it didn't ask permissions. I had to manually go and set that config to get it to ask.
There may be differences based on whether the command is under the directory you're running OpenCode from vs some other directory...
The world is filled with "good enough" solutions. If it has 80% of the functionally needed, it will be good enough for most use cases.
> the most meritorious solution never rises to the top
You know why? Because it was the best solution at the time that covered everything they needed. You can only complain about it because the initial problem was solved and people were able to move on to something else.
Does it work for what we need it to do? Yes? Ok. Now that we have settled this problem, we can continue on developing.
Meritocracy is only relevant to someone who has ideas but no desire or ability to actually structure the idea in such a way that would work in the world we find ourselves in today.
> Maybe D-Bus has something similar?
So you just commented here to say nothing but "dbus sucks because it isn't the best. I wonder if there are better options?".
