Error 400: what to do when glm-4.5 fails

A 400 means the request itself is invalid — a missing field, a wrong type, or a parameter this model does not support. Retrying will not help; the request body must change.

400 Bad Request means the server refuses to process the request because the body itself is invalid. Unlike 5xx, a 400 will not resolve by retrying — you get the same response every time. The parameters must be fixed first.

glm-4.5 is served by Z.AI. Everything on this page — triggers, fixes and measured data — is compiled from the real runtime behaviour of this model at the gateway layer.

At this gateway, the most common trigger is: A required field is missing (model or messages). The recommended first action is: Check the request body against the parameter table on this page.

Common causes

  • A required field is missing (model or messages)
  • A parameter has the wrong type
  • A parameter is not supported by this model
  • messages is malformed or role has an invalid value

How to fix

  • Check the request body against the parameter table on this page
  • Remove unsupported parameters and retry
  • Make sure messages is an array with valid role values
  • Start from a minimal request, then add parameters one by one

Retry with exponential backoff

The snippet below retries when glm-4.5 returns 400, up to 5 attempts, with an increasing wait plus random jitter so concurrent calls do not retry in lockstep. Read the base URL and API key from environment variables — never hardcode them.

import os, time, random
import requests

BASE  = os.getenv("OPENAI_BASE_URL")   # e.g. https://<your-gateway>/v1
KEY   = os.getenv("OPENAI_API_KEY")
MODEL = 'glm-4.5'


def chat(messages, retries=5):
    """Retry with exponential backoff + jitter."""
    for i in range(retries):
        try:
            r = requests.post(
                BASE + "/chat/completions",
                headers={"Authorization": "Bearer " + KEY},
                json={"model": MODEL, "messages": messages, "stream": True},
                timeout=60,
            )
            if r.status_code == 429 or r.status_code >= 500:
                time.sleep(min(2 ** i + random.uniform(0, 1), 30))
                continue
            r.raise_for_status()
            return r.json()
        except requests.exceptions.Timeout:
            time.sleep(min(2 ** i + random.uniform(0, 1), 30))
    raise RuntimeError("gave up after " + str(retries) + " retries")


print(chat([{"role": "user", "content": "hello"}]))

Key facts for this model

API endpointhttps://api.airai.cc/v1
OpenAI-compatibleOpenAI-compatible
VendorZ.AI
Context131.1K
CapabilitiesReasoning, Tools, Open Weights
API formatsopenai, openai-response, openai-response-compact, anthropic, gemini, openai-alpha-search
Billing formulap * 0.6 + cr * 0.11 + cc * 0 + c * 2.2

FAQ

Do failed requests count against my rate limit quota?

Only the output already produced is billed; the failed part is not. With billing p * 0.6 + cr * 0.11 + cc * 0 + c * 2.2, the cost of long output comes mostly from output tokens. Check your balance and rate limits in the console before debugging code. When estimating cost from p * 0.6 + cr * 0.11 + cc * 0 + c * 2.2, include the retry budget.

Does sharing one key across several services make 400 more likely?

It is mainly a quota matter, not a fault in the model itself. Billing follows p * 0.6 + cr * 0.11 + cc * 0 + c * 2.2, so no output means no charge. With billing p * 0.6 + cr * 0.11 + cc * 0 + c * 2.2, failed requests are not counted toward usage. When estimating cost from p * 0.6 + cr * 0.11 + cc * 0 + c * 2.2, include the retry budget.

Can switching to another model work around 400 on glm-4.5?

Keep a fallback model ready as well. Building a fallback into the architecture is more reliable than patching errors one by one. This model from Z.AI has several upstream nodes the gateway can switch between. Keep a lighter fallback model ready so the main flow never breaks. Put the model name in config, so switching upstreams needs no code change.

How should I schedule batch jobs when glm-4.5 returns 400?

Concurrency and timeouts are the real variables here, not the model itself. Lower the concurrency first — most throughput complaints disappear once you do. This model has a 131.1K context window and comes from Z.AI. A 131.1K context means long inputs add noticeably to first-token latency. Use batching or a queue to smooth peaks — steadier than raising concurrency on the fly.

Other errors on this model

Other models with the same error

Back to the model page

Data updated: 2026-10-10 18:35

Technical SupportLive Support
Back to Top