Ollama cloud default in 2026: glm-5.2 vs kimi-k3 vs deepseek-v4-flash for boring backend work

Do not pick this from a thread, including this one. Two hours of measurement now saves you months.

Take ten tasks you actually did last week — real tickets from your real repo, not toy prompts. Write down the acceptance criteria for each. Run all ten through each candidate model from a fresh session. Record two things: did it pass, and how far did the session bar move.

You will end up with a table that says something like "model A passes 8/10 at one unit of cost, model B passes 9/10 at four units". Then the routing rule writes itself, and it is your routing rule rather than mine.

Two-tier routing, and pick the tiers by activated parameters rather than by total.

On a mixture-of-experts model, the compute per generated token tracks the parameters that are actually active for that token, not the headline count. deepseek-v4-flash publishes 13B activated out of 284B. That is a completely different cost profile from a model that activates a much larger slice, even though both numbers look enormous in the model name.

So: small-active model as the implementer for edits, refactors, test fixes and tool loops. Big model reserved for planning and for the genuinely hard debugging session. In my week that ends up being roughly ninety percent of turns on the cheap tier.

Caveat that this is my repo and my prompts. The ratio will not transfer.

For code specifically I have kimi-k2.7-code as the workhorse and k2.6 for the cheap mechanical stuff, escalating to glm-5.2 for maybe one task in twenty. That split has held for a few weeks.

Stated plainly as my result on my codebase: TypeScript services, heavy tool use, medium-sized files. Nobody should adopt it without running their own ten tasks through it first. The reason it works for me is that the escalation is rare enough that the expensive model never gets a chance to dominate the window.

Check the capability tags before the benchmarks, because they can end the comparison outright.

kimi-k3, kimi-k2.7-code, kimi-k2.6 and qwen3.5 all carry a vision tag. glm-5.2 is listed with tools and thinking but no vision. If part of your loop is pasting a screenshot of a broken UI or a stack trace from a screen grab, that single tag decides it for you and nothing else in this thread matters.

Ignore context length in this decision unless you genuinely use it. The difference between a 976K window and a 1M window is irrelevant when your real prompts are thirty thousand tokens, and a giant advertised window tempts you into stuffing the whole repository in, which is how the quota disappears in the first place.

Pick on cost per completed task. Context is a constraint to check, not a feature to buy.

Or sidestep the whole quota question and run glm-5.2 locally. Open weights, no meter, no five hour window.