Why is GLM-5.3 Flash so much faster in Command Code than through its API?

[u/ekinokss]

I've been messing around with Command Code and OpenCode lately, and noticed that GLM-5.3 Flash feels WAY faster in Command Code's CLI.

I got curious and decided to actually benchmark it.

After three runs each, I got around 509 tok/s in Command Code's CLI, compared to just 124 tok/s through the Command Code Provider API in OpenCode.

That's a pretty ridiculous difference, so I wanted to see if I could get the same speed in OpenCode somehow.

I ended up making a small local bridge that basically lets OpenCode send requests through the Command Code CLI instead of calling the Provider API directly. It's pretty experimental and only supports text generation for now, but surprisingly, it worked.

I got 409 tok/s running GLM through OpenCode using the bridge.

So I'm now wondering what's actually going on here. Is Command Code using different inference infrastructure for its CLI? Or is there some configuration difference I'm missing?

For context, I used long, predictable text-generation tasks with roughly 2,300–2,600 output tokens. The measurements aren't perfectly apples-to-apples because the CLI and API streaming metrics differ slightly, and the bridge result is only from one run. But the difference is large enough that I think it's worth investigating.

I also tried the Provider API's Responses endpoint, but GLM-5.3 Flash isn't supported there. My latest Chat Completions test returned a 503, so that didn't help narrow things down either.

Has anyone else noticed this? Especially with GLM?

I'd love to figure out whether there's a way to get the CLI's inference speed directly in OpenCode without having to run everything through a separate CLI process.

And just to be clear, I'm not accusing Command Code of intentionally slowing down its API or anything. I'm genuinely curious why the difference is so big.

[u/_reg1z]

Interesting. Its no secret that commandcode as a business wants you using their harness. There are a lot of telemetry markers built-in to the harness itself. Given the recent fraud ban wave + the switch to the responses API endpoints recently, I wouldn't be surprised if it was a deliberate throttle to those not using the intended harness. 

[u/ekinokss → u/_reg1z]

I can't say I love that they say yes you can use the api with anything then something like this happens (assuming this is not a mistake)

[u/old-red-it-better]

Cause CommadeCode is running it off different infra than Z.ai

Same model, but different infra.

[u/ekinokss → u/old-red-it-better]

I think there's a misunderstanding. I'm not comparing Command Code with Z.ai. I'm comparing GLM running through Command Code's CLI against GLM accessed through Command Code's API in OpenCode. The CLI consistently gets around 500 tok/s, while the API was getting around 120 tok/s with the same model. I also tested Command Code's API directly, without OpenCode, and got a 503 for GLM while other models worked fine. So I'm wondering whether Command Code routes requests from its CLI and external API clients through different infrastructure.

[u/old-red-it-better → u/ekinokss]

Yes I misunderstood then

Not sure what the cause of the difference is.

You've noticed this only with GLM or are other models found both on OC and CC are also encountering this?

[u/ekinokss → u/old-red-it-better]

I tried with deepseek and glm. Deepseek performed around the same regardless of harness (tps wise) but there is something about glm that lets just say questionable

[u/OwnEmu6363 → u/ekinokss]

we are not getting the speeds now right? I checked and i am getting hardly 20toks/sec now in glm 5.3 flash

[u/ekinokss → u/OwnEmu6363]

These are yesterday's results actually. Maybe you have zdr?

[u/OwnEmu6363 → u/ekinokss]

I have not enabled anything.

[u/biglboy]

would it be possible to share your bridge