Zhipu drops GLM-5 and goes all in on GLM-5.1.

Zhipu has made a move.

On April 8, Zhipu announced through its official developer WeChat community that the GLM-5 model would be officially discontinued and the CodingPlan product line, among others, would be fully migrated to GLM-5.1. As soon as the news broke, the developer community erupted — some applauded, while others got ready to vent.

This is not just a simple version-update notice. Behind it lies a tough choice Zhipu made regarding compute resource allocation.

Why cut off GLM-5?

The direct reason: not enough compute to go around.

According to community developers’ feedback and analysis, GLM-5 and GLM-5.1 share the same base model. GLM-5 has 744B total parameters, activates 40B per inference, and uses an MoE (Mixture of Experts) architecture. GLM-5.1 builds on that foundation with further optimization — Zhipu’s official data shows that under the same time window, its effective optimization capability reaches 1.4× that of GLM-5.

The issue came from user behavior. GLM-5.1 is clearly stronger, which led to heavy user traffic during peak hours, while GLM-5’s usage gradually declined. Running both models simultaneously scattered available compute, resulting in 5.1 often having queues, slower token output, and limited concurrency — degrading overall experience.

A developer on the forum put it bluntly: “Few people use 5 during the afternoon peak, but 5.1 is jam-packed.”

Zhipu’s choice: rather than doing both poorly, focus on one. Kill GLM-5 and funnel all compute power into GLM-5.1.

The three questions developers care most about

Will the speed improve?

This is the most frequently mentioned pain point in the community.

Before GLM-5 was removed, developers often complained about GLM-5.1’s inference speed. “Painfully slow output” and “crazy concurrency limits” were common phrases. Some heavy users who spent thousands bluntly said that if the speed issue remained unresolved, they would “immediately start roasting it.”

Technically speaking, consolidating compute resources should bring improvement. One of GLM-5’s key technical breakthroughs was reducing KV Cache overhead by 75%, meaning the same GPU could support over 4× the concurrent requests or handle 4× longer context. GLM-5.1 inherits this optimization. Now that all compute originally allocated to GLM-5 is freed up for 5.1, concurrency and response speed should theoretically improve significantly.

But theory is one thing. Some developers used third-party relay endpoints (like ZAI) combined with NewAPI’s auto-retry mechanism to mitigate concurrency issues and reported that “the slow output weakness remains.” Whether this adjustment truly solves the problem depends on actual performance.

One interesting detail: some developers said for simpler tasks, they’d rather use GLM-Turbo than the flagship model. That suggests GLM-5.1 still has room to improve its cost-effectiveness in lightweight scenarios. If Zhipu simply piles on compute power without refining scheduling strategy, simple requests might still be dragged down by a heavy model.

Will the price go up?

This is the second sensitive topic.

On the same day, media reported that Zhipu had increased GLM-5.1’s price by about 10%. Community members have already been crunching numbers: “Does that make the price almost the same as Claude?”

Currently, existing CodingPlan users still pay the old rate — ¥200/month for 150 million tokens within a 5-hour window. But Zhipu hasn’t clarified whether pricing will change for new users.

There’s a subtle game at play here. Zhipu’s competitive strategy has long relied on price advantage, especially in the domestic market — compared to calling Claude or GPT-4o, the GLM series’ cost advantage is a major reason many teams choose it. If prices really approach Claude’s level, developers will recalculate: for the same money, should I use a domestic model or just call Claude directly?

Of course, the GLM series has an edge Claude and GPT do not — direct domestic access, with no need to wrestle with proxies or network issues. For production environments, stability and compliance sometimes matter more than raw performance.

Is the migration costly?

Zhipu has already published a migration guide. Switching API calls from GLM-5 to GLM-5.1 requires minimal changes. If you were using OpenAI-compatible endpoints, you basically just change the model name.

For developers using API aggregation platforms, migration is even simpler. For example, if you’re calling through an OpenAI-format-compatible aggregator like OpenAI Hub, just change the model parameter from glm-5 to glm-5.1 — no other code changes needed:

from openai import OpenAI

client = OpenAI(
    api_key="your-openai-hub-key",
    base_url="https://api.openai-hub.com/v1"
)

response = client.chat.completions.create(
    model="glm-5.1",  # changed from glm-5 to glm-5.1
    messages=[
        {"role": "system", "content": "You are a programming assistant"},
        {"role": "user", "content": "Implement a simple LRU cache in Python"}
    ],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

If you’re using GLM-5.1’s new streaming tool-call capability, you can invoke it like this:

response = client.chat.completions.create(
    model="glm-5.1",
    messages=[
        {"role": "user", "content": "Check today’s weather in Beijing for me"}
    ],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather information for a specified city",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "City name"}
                },
                "required": ["city"]
            }
        }
    }],
    stream=True  # GLM-5.1 supports streaming tool calls
)

Streaming tool calls are a substantial improvement over GLM-5. Before, developing Agents with GLM-5 required waiting for the full response before parsing tool calls. Now, processing can happen as generation unfolds — greatly improving the experience for real-time feedback applications.

What exactly makes GLM-5.1 stronger than GLM-5?

Stripping away marketing copy, GLM-5.1’s core improvements center on three aspects:

1. Sustained inference capability. Zhipu’s data shows that GLM-5’s performance curve on complex tasks flattens earlier, while GLM-5.1 maintains effective optimization longer, ultimately achieving 1.4× the performance of GLM-5. In plain terms: faced with complex programming or long reasoning chains, GLM-5 tends to “give up halfway,” while GLM-5.1 persists longer and delivers more complete solutions.

2. Tool-calling capabilities. GLM-5.1 supports streaming tool calls and structured outputs — features that make its behavior more mature in Agent scenarios. For teams building AI applications, these capabilities directly impact product experience.

3. Long-session work endurance. Zhipu claims GLM-5.1 can maintain effective work for 8 hours. This metric mainly applies to programming-assistant scenarios like CodingPlan — the model can sustain context understanding and code quality throughout long sessions without “forgetting what was said earlier.”

Still, whether these improvements justify a 10% price increase — that’s something each developer will evaluate for themselves.

The bigger picture

Viewed in the broader context of China’s large-model competition, Zhipu’s move is quite interesting.

Over the past year, domestic model vendors have been locked in a “price war” — “You cut your price, I cut mine,” some almost giving models away for free. But by 2026, the winds are changing. Model performance gaps are narrowing while compute costs haven’t fallen proportionally, and vendors are realizing they can’t win users by burning money forever.

Zhipu’s decision to shut down older models, consolidate resources into one stronger model, and slightly raise prices marks a shift from “land grab” to “refined cultivation.” Whether this strategy succeeds depends on whether GLM-5.1’s experience truly supports its new price point.

For developers, this sends a signal: don’t put all your eggs in one basket. Model providers can adjust product strategies at any time — a model that works perfectly today might be discontinued tomorrow. Maintaining multi-model compatibility and implementing standardized API abstraction layers is becoming increasingly important in engineering practice.

What to watch next

In the short term, several indicators are worth monitoring:

• GLM-5.1’s actual inference speed and concurrency after compute consolidation, especially during weekday afternoons
• Whether new CodingPlan user pricing changes
• Whether existing users’ benefits change upon renewal
• Community developers’ real-world feedback, especially head-to-head comparisons with Claude 4 and GPT-4o

Zhipu’s bet is that making one model extremely good is more valuable than maintaining two mediocre ones. That judgment is likely correct. But whether the execution delivers will be proved by speed and stability.

After all, developers are the most pragmatic crowd — if it works well, a single test run will show it.

---

References:

• GLM official CodingPlan removes GLM-5 – Developer community discussions — A summary of community developers’ discussions and feedback on the takedown